feat: prefer fewer charging interruptions - #151

Like it. This reduces breaks and helps a lot. I even could imagine to have a small cost factor applied which would not be that wrong but is difficult to define. Happy with the current idea.

Looks like it would solve the issues in my last two auto-mode planner test runs: evcc-io/evcc#33763 (comment)

Here the 5-min snapshots from optimizer during my last charging session. It shows the jumping scheduled charging slots between solves. evopt-history.zip

I used the cloud instance that should have this fix preview-deployed already (@andig). So it does not seem to work as intended yet.

There is a chance that equal costs is not true hence the tie break is not applied. Needs to check the logs in detail to be sure because of that.

It seems this is not about interruptions but about influencing an equal-cost solve into a particular direction so they remain stable across solves? Which direction would that be and how would be formulate this mathematically?

I analyzed the 108 snapshots from evopt-history.zip (5-minute cadence, 2026-09-16 23:18 → 2026-09-17 08:47) to see what actually changes between solves.

Setup in the data

• Horizon 48 h, 195 slots, slot 0 truncated to the next quarter (dt[0] ranges 9…899 s).
• Two storages, both with the same p_a = 0.000172854 €/Wh:
  • car db:17, 68 kWh, c_min 4140 W, c_max 11000 W, s_initial 25160 Wh, s_goal 40800 Wh by 2026-09-17 05:45
  • home battery db:24 (Sungrow), 22.4 kWh
• Prices: import 0.194 €/kWh 00:00–05:00, 0.3133 €/kWh afterwards; export flat 0.11 €/kWh.

What is stable, what jumps

The block that actually controls charging is stable for four hours of solves: 09-17 03:15–04:45, 17.4 kWh at 11 kW.

What jumps is:

1. the day-2 (09-18) PV-surplus block assigned to the car,
2. the residual ~1.5 kWh after 05:00,
3. the slot-0 command itself.

Cause 1 — the car/home-battery split is degenerate

Two plan families alternate across solves:

Grid export is zero in 100 of 108 solves, so the whole PV surplus is absorbed either way. Total stored energy, grid import and grid export are identical between the families — only the split between car and home battery differs. Since p_a is the same for both storages, the objective cannot distinguish them.

Objective values confirm this. Within each quarter-hour the objective is linear in dt[0], so I regressed it out and extrapolated to dt[0] = 0 for the quarters 00:30–03:00, where the inputs are essentially unchanged (s_initial constant at 25160 Wh):

Same within ±0.002, with no systematic ordering. The alternation is not one solve finding a better plan — both plans are optimal, and which one comes back is arbitrary.

Cause 2 — price plateaus

All slots 00:00–05:00 carry one price, so any placement of the remaining energy inside that window costs exactly the same. The same holds after 05:00 (all 0.3133 €/kWh), which is why the last 1.5 kWh floats between 05:15, 05:30 and 05:45 across the solves at 05:02, 05:07, 05:12 and 05:23.

The inputs do not explain the jumping

I compared consecutive requests on their shared timestamp grid. 59 consecutive pairs have byte-identical ft, gt, p_N and p_E for every shared slot. 25 of those 59 still returned a different on/off pattern, up to 11 slot flips:

So the change originates inside the solve (branching order, incumbent at the cutoff), not in the data.

Effect on the real charging session

Commanded slot-0 power for the car, while it still needed energy:

Full stops are commanded at 03:26, 04:40, 05:02, 05:07, 05:12 and 05:23 — that matches the interruptions you observed.

Why the tie-break in this PR does not bite here

Family A has fewer car blocks than family B (2 versus 3 over the whole horizon), yet family B is returned in roughly 40 of the solves. Two things are visible in the data:

• the tie-break has no memory of the previous schedule, so nothing anchors solve N to solve N−1 — on a rolling horizon a degenerate optimum simply re-rolls every five minutes;
• the alternation is across the car/home-battery split, which is a tie between two different storages, not between two schedules of the same one.

A within-solve tie-break alone cannot stabilize this. What the data suggests is needed:

1. cross-solve anchoring — pass the previous schedule (or at least the currently active state of each storage) into the request and penalize deviation within the already-bounded cost-neutral budget;
2. a deterministic secondary criterion when two storages share the same p_a, so the surplus split stops flipping (for example prefer the storage that can discharge, or earliest and contiguous).

Side finding

The solve at 2026-09-16 23:31 (evopt-20260916-233115.json) used a different demand series than both its neighbours — gt differs by up to 306 Wh per slot on all 193 shared slots — and returned objective_value 4.4362 with 38.1 kWh scheduled into the car. The next solve, 20 seconds later, is back to the normal series and 23.1 kWh. Looks like a one-off bad demand forecast sample, probably worth a separate look.

🤖 Generated with Claude Code

Since p_a is the same for both storages, the objective cannot distinguish them.

p_a is the end of horizon value for stored energy. There's only one global setting. We could of course split these per battery type. However, there is an additional issue that I have no idea how to address:

• if we push vehicle before home battery we may not have enough home battery for the night
• if we push home battery before vehicle you have the risk of the vehicle leaving later leading to unused surplus

You loose either way.

To anchor a solve seems appropriate to me as well. We've had quite comparable situations by the continuous planner if I remember it correct.
Thanks for the approaches!